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Description 

Background of the Invention 



Traditionally, computer display screens have been 
designed either to provide a 'portrait' orientation, in 
which the vertical dimension is greater than the horizon- 
tal dimension, or to provide a 'landscape' orientation, 
in which the horizontal dimension is greater than the ver- 
tical dimension. Recent advances in technology have 
made possible the use of both portrait and landscape 
orientations with the same computer. Some computer 
display systems allow the user of the computer to repo- 
sition a display screen between portrait and landscape 
orientations, and some computers allow the simultane- 
ous use of multiple display screens. 

When the orientation of a display screen is reposi- 
tioned between portrait and landscape orientations, 
some display area is necessarily lost from view and oth- 
er area is gained. In a computer system that uses 'win- 
dow' based displays, the area that is lost may include 
important portions of a window necessary to allow the 
user to move or resize the window. There may also be 
other screens displaying data which do not change in 
orientation. In order to ensure that the resulting display 
is usable, some method for automatically redefining the 
coordinate system of the computer displays in the sys- 
tem, and resizing and moving windows, is desirable. 

Known systems exist for modifying windows dis- 
played on a fixed display screen. For example, E.S. Co- 
hen et al., "Automatic strategies in the Siemens RTL 
tiled window manager', 2nd IEEE Conference on Com- 
puter Workstations, March 7-10, 1988 Santa Clara (Cal- 
ifornia) discloses automatic adjustment of size and po- 
sition of tiled windows to balance competing demands 
for screen space. The EP-A-0 156 116 discloses a split 
screen divider that is dynamically and interactively 
moveable. 

Summary of the Invention 

Accordingly, the present invention provides a meth- 
od to resize and move windows on a computer display 
system when a display screen comprising part or all of 
the computer display system is repositioned between 
portrait and landscape orientations. Consideration is 
given to the display area lost due to the change in ori- 
entation, the display area gained due to the change in 
orientation, and, if multiple display screens are involved, 
whether the change in orientation of one screen should 
cause a change in the coordinate definitions of any other 
screens. 

Brief Description of the Drawings 

Figure 1a shows the change from portrait to land- 
scape orientation. 

Figure 1 b shows the display area removed and add- 
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e change in orientation illustrated 



ed as the result 
in Figure 1a. 

Figure 2 shows a portrait ri ntation screen with two 
windows. 

5 Figure 3 shows how the screen of Figure 2 is dis- 
played in landscape orientation in accordance with the 
present invention. 

Figure 4 shows a portrait orientation screen with 
portions of two windows. 
10 Figure 5 shows how the screen of Figure 4 is dis- 
played in landscape orientation in accordance with the 
present invention. 

Figures 6a and 6b show the portion of a display on 
a filed-orientation screen, both before and after the ori- 
75 entation of a second associated screen is repositioned 
from portrait to landscape orientation, respectively. 

Figure 7 shows a screen in portrait orientation with 
one window. 

Figure 8 shows a screen in portrait orientation with 
20 the same window as shown in Figure 7 after that window 
has been enlarged by zooming in the traditional manner. 

Figure 9 shows how the screen of Figure 8 is dis- 
played in landscape orientation in accordance with the 
present invention. 
2S Figure 10 shows a screen in landscape orientation 
with the same window as shown in Figure 8 after the 
screen orientation has been repositioned from portrait 
to landscape orientation with the automatic zoom fea- 
ture operative in accordance with the present invention. 
^0 Figure 11 shows a control panel display window for 
selecting features in accordance with the present inven- 
tion. 

Figures 11 (a) and 11(b) detail the window resizing 
portion of the control panel display window with the auto- 
55 rezoom facility of the window resizing feature enabled 
and disabled, respectively. 

Figure 12 shows a control panel display window for 
disabling features and providing custom commands for 
selected window types in accordance with the present 
to invention. 

Figure 1 3(a) shows a block diagram of software 
patches to prior art software routines in accordance with 
the present invention. 

Figure 13(b) shows a block diagram of software 
46 support routines in accordance with the present inven- 
tion. 

Figure 14 shows a flow diagram of the software 
patch, in accordance with the present invention, to the 
prior art routine _SlotManager 
50 Figure 15 shows a flow diagram of the software 
patch, in accordance with the present invention, to the 
prior art routine _GetNextEvent. 

Figure 16 shows a flow diagram of the software 
patch, in accordance with the present invention, to the 
55 prior art routine JnitGraf. 

Figure 17 shows a flow diagram of th software 
patch, in accordance with the present invention, to the 
prior art routine _NewWindow. 
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Figure 18 shows^Wlow diagram of the software 
patch, in accordance with the present invention, to the 
prior art routine JnitWindows. 

Figure 19 shows a flow diagram of the software 
patch, in accordance with th present invention, to the s 
prior art routine _SelectWindow 

Figure 20 shows a flow diagram of the software 
patch, in accordance with the present invention, to the 
prior art routine _C lose Window. 

Figure 21 shows a flow diagram of the software 10 
patch, in accordance with the present invention, to the 
prior art routine _DragWindow. 

Figure 22 shows a flow diagram of the software 
patch, in accordance with the present invention, to the 
prior art routine _ShowHide. is 

Figure 23 shows a flow diagram of the software 
patch, in accordance with the present invention, to the 
prior art routine _GrowWindow. 

Figure 24 shows a flow diagram of the software 
patch, in accordance with the present invention, to the so 
prior art routine _SizeWindow. 

Figure 25 shows a flow diagram of the software 
patch, in accordance with the present invention, to the 
prior art routine _ZoomWindow 

Figure 26 shows a flow diagram of the software 2S 
patch, in accordance with the present invention, to the 
prior art routine _MenuSelect 

Figure 27 shows a flow diagram of the software 
patch, in accordance with the present invention, to the 
prior art routine _TrackBox. 30 

Figure 28 shows a flow diagram of the software 
patch, in accordance with the present invention, to the 
prior art routine _GetMouse. 

Figure 29 shows a flow diagram of the software 
patch, in accordance with the present invention, to the 35 
prior art routine .Button. 

Figure 30 shows a flow diagram of the software 
patch, in accordance with the present invention, to the 
prior art routine _TextBox. 

Figure 31 shows a flow diagram of the software <o 
patch, in accordance with the present invention, to the 
prior art routine JnitZone. 

Figure 32 shows a flow diagram of the software rou- 
tine Check/Handle Flip in accordance with the present 
invention. as 

Figures 33(a), 33(b), 33(c) and 33(d) show a flow 
diagram of the software routine Compute New Window 
in accordance with the present invention. 

Figures 34(a) and 34(b) show a flow diagram of the 
software routine Check Resize List in accordance with so 
the present invention. 

Figure 35 shows a flow diagram of the software rou- 
tine Resize Window in accordance with the present in- 
vention. 

Figure 36 shows a flow diagram of the software rou- ss 
tine Compute Resize Am unt in accordance with the 
pr sent invention. 

Figures 37(a), 37(b), 37(c) and 37(d) show a flow 
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diagram f the sBTTwar routine Rebuild Desktop in ac- 
c rdance with the present invention. 

Figure 38 shows a flow diagram of the software rou- 
tin Finder Cleanup in accordance with the present in- 
vention. 

Figur 39 shows a flow diagram of the software rou- 
tine Map Rectangle to Main Device in accordance with 
the present invention. 

Figure 40 shows a flow diagram of the software rou- 
tine Process a New Window in accordance with the 
present invention. 

Figures 41 (a) and 41 (b) show a flow diagram of the 
software routine Get Window's Graphic Device in ac- 
cordance with the present invention. 

Detailed Description of the Invention 

Referring now to Figure 1a, there is shown a com- 
puter display screen which may be operated either in 
portrait orientation 1 or landscape orientation 2. With 
some display screens, it is possible to reposition, or flip' 
the orientation of the screen at any time. Figure 1b 
shows that when such a flip occurs from portrait orien- 
tation 1 to landscape orientation 2, some display area 4 
will be removed, a corresponding area 5 will be added, 
and some display area 3 will be neither removed nor 
added. 

Figure 2 shows a display 1 in portrait orientation 
with a smaller window 10, a larger window 11 , a main 
menu bar 12 and two icons 13. In accordance with the 
present invention, a flip from the portrait orientation of 
Figure 2 results in the resizing or moving of the smaller 
and larger windows 10, 11, the main menu bar 12 and 
the two icons 1 3. The display which results from such a 
flip is shown in Figure 3. The smaller window 10 is 
moved vertically upward to fit entirely within the confines 
of the landscape display 2, the vertical dimension of the 
larger window 1 1 is reduced to fit entirely within the con- 
fines of the landscape display 2, the horizontal dimen- 
sion of the main menu bar 1 2 is increased to completely 
reach from the left side of the landscape display 2 to the 
right side of the landscape display 2, and the icons 1 3 
are moved further away from the larger window 1 1 . 

It is desirable to have windows and menu text which 
were visible and accessible before a flip remain visible 
and accessible after a flip It is also desirable to have 
the portions of windows which were accessible before 
the flip remain accessible after a flip. If the computer 
display system makes use of other display screens than 
the one which is flipped, then it is desirable that the im- 
pact of a flip on those other display screens should be 
minimal, in addition, if the main menu bar appears be- 
fore the flip, then it must change in size in accordance 
with the new dimensions of the flipped display screen. 
Similarly, icons must remain accessible in both orienta- 
tions of the display screen. 

Accordingly, the present invention determines 
which display screen in a computer system having mul- 



3 



EP 0 439 087 B1 



tiple display screens s^iRJ control a particular window. 
This is accomplished by weighting the importance of the 
various edges ol a window, determining which window 
edges appear on which display screen, and computing 
a weighted sum for each display screen. One emb di- 
ment of the present invention uses the following weight- 
ing scheme: 

8 is added to the weighted sum for a display screen 
if that display screen contains the top edge of the win- 
dow. 

4 is added to the weighted sum for a display screen 
if that display screen contains the left edge of the win- 
dow. 

2 is added to the weighted sum for a display screen 
if that display screen contains the right edge of the win- 
dow. 

1 is added to the weighted sum for a display screen 
if that display screen contains the bottom edge of the 
window. 

Thus, if a display screen contains the entire window, 
the sum is 1 5, and if the display screen does not contain 
any portion of the window, the sum is 0. The display 
screen which has the highest sum for a window is con- 
sidered to control that window. If no display screen con- 
tains a sum greater than 0, the window is controlled by 
whichever display screen contains the main menu bar. 
The top edge of a window is considered the most impor- 
tant edge because it normally contains the title bar for 
the window, which is used for manual placement, zoom- 
ing, and closure of the window. 

In accordance with the present invention, when a 
display screen which contains the entirety of a window 
is flipped, the window is resized and moved as required 
to ensure that the window remains in its entirety on the 
flipped display screen. An example of this is shown in 
Figures 1 and 2, where the small and large windows 10 
and 11 are retained entirely in the landscape display 2 
after the flip. A vertical move of the smaller window 10 
allows it to fit within the landscape display 2. The larger 
window 10 in the portrait orientation display 1 of Figure 
2 is too tall to fit in the landscape display 2 of Figure 3, 
even if the larger window 1 0 is moved as far up vertically 
as possible. Therefore, the larger window 10 is resized 
to a smaller vertical dimension in order to allow the win- 
dow 10 to fit in the landscape display 2 of Figure 3. in 
the preferred embodiment of the invention, this resizing 
is accomplished by software which mimics the code 
generated by a pointing device (or 'mouse") to resize 
windows manually. 

In the preferred embodiment, the initial location and 
size of windows 10 and 11 are stored in memory when 
the display screen is flipped so that flipping the display 
screen back to its original orientation results in a display 
identical to the initial display. However, if the user chang- 
es the size or locations of windows on the flipped display 
screen, flipping the display screen back to its original 
orientation will not result in a display identical to the in- 
itial display. 



Referring no^o Figure 4, windows 21 and 22 are 
shown only partially contained in the portrait display 1 
In accordance with the pr sent invention, when the dis- 
play screen is flipped, the top-left edge of each of the 
5 windows 21 : 22 is kept the same distance from which- 
ev r edges of the display that the window extends be- 
yond, as illustrated in Figure 5. In Figufe 4, the window 
21 extends below the bottom edge 23 of the portrait dis- 
play 1 . When the display screen is flipped as shown in 
io Figure 5, the top-left edge of window 21 is maintained 
at the same distance from the lower edge 23 of the land- 
scape display 2. Similarly, in Figure 4, the window 22 
extends past the right edge 24 of the portrait display 1 . 
When the display screen is flipped, as shown in Figure 
is 5, the top-left edge of window 22 is maintained at the 
same distance from the right edge 24 of the landscape 
display 2. The vertical dimension of window 22 is also 
decreased in the change of orientation from Figure 4 to 
Figure 5 to maintain the lower edge of window 22 on the 
20 lower border of the landscape display 2, as illustrated in 
Figure 5. As in the previously described situation, the 
initial location and size of the windows are stored in 
memory for use in the event the display screen is flipped 
back to its original orientation without the user having 
25 made any changes to the size or location of the win- 
dows. 

Referring now to Figure 6a, a coordinate system is 
used to define locations on the display screens 34, 35. 
In this case, display screen 34 is a portrait orientation 

30 on a display screen capable of flipping, and display 35 
is a portrait orientation on a fixed-orientation display 
screen. One embodiment of the present invention uses 
a coordinate system having its origin 30 at the top-left- 
most displayed pixel and including a first number that 

35 refers to the number of pixels below the origin, and a 
second number that refers to the number of pixels to the 
right of the origin. Thus, as illustrated in Figure 6a, it the 
portrait orientation of display screen 34 is 665 pixels 
high by 640 pixels wide, the bottom-rightmost pixel 32 

40 will have the coordinates (863, 639). Similarly, the top- 
leftmost pixel 31 of the fixed-orientation display 35 will 
have the coordinates (0,640) and the bottom-rightmost 
pixel 33 of the fixed-orientation display screen 35 will 
have the coordinates (863, 1279). A window 38 con- 

45 tamed entirely on the fixed-orientation display screen 
35, as illustrated in Figure 6a, has a top left corner 36 
with the coordinates (100,800) and a tower right comer 
37 with the coordinates (700, 1100). 

When the display screen 34 is flipped, the coordi- 

50 nate system changes. Referring now to Figure 6b, the 
portrait display screen 34 of Figure 6a is illustrated as 
flipped to a landscape-oriented display screen 41. The 
origin 42 of the landscape-oriented display screen 41 
retains the coordinates (0,0), but the bottom-rightmost 

55 corner 44 of the landscape-oriented display screen 41 
now has the coordinates (639, 863). The top-rightmost 
pixel 43 of the fixed-orientation display screen 35 now 
has the coordinates (0, 864), and the bottom-rightmost 
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pixel 45 of display scrSSff 35 now has the coordinat s 
(B63, 1503). The ccx>rdinates of the top-leftmost corner 
39 and bottom-rightmost 40 comer of the window 38 in 
the fixed portrait-oriented display screen 35 become 
(100, 1024) and (700, 1 324), respectively. The local co« s 
ordinate system of the fixed-orientation display scr en 
35 thus changes as a result of flipping the portraitori- 
ented display screen 34 to a landscape-oriented display 
screen 41. In the preferred embodiment, the coordi- 
nates of a window 36 controlled by a fixed-orientation 10 
display screen 35 are adjusted so that the location of 
the window 38 relative to the top-leftmost pixel 43 of the 
fixed-orientation display screen 35 remains unchanged 
after the other display screen 34 is flipped. 

Figures 7 through 10-illustrate how windows may *5 
be enlarged via /zooming" in accordance with the 
present invention. In Figure 7, the portrait-oriented dis- 
play screen 1 completely contains a window 51 , and al- 
so contains a title bar 1 2 and icons 1 3. Figure 8 shows 
the window 51 of Figure 7 enlarged via conventional 20 
zoom processing available in the prior art. The zoomed 
window 52 in Figure 8 is illustrated as enlarged to fill the 
screen as completely as possible without covering the 
menu bar 12 or the icons 13. Figure 9 shows the result 
of flipping the portrait-oriented display screen 1 of Fig- 2S 
ure 8 to a landscape-oriented display screen 2. The ver- 
tical dimension of the window 52 in Figure 6 is reduced 
in the window 53 of the landscape-oriented display 
screen 2 of Figure 9 in order that the entire window 53 
remains on the landscape-oriented display screen 2 of 30 
Figure 9. The icons 1 3 are also moved so that they fit in 
the rightmost area of the landscape-oriented display 
screen 2 of Figure 9. Conventional zoom processing of 
the window 52 in Figure 8 thus does not result in suffi- 
cient expansion of the window 53 to fill the screen after 3S 
the screen has been flipped to a landscape-oriented dis- 
play screen 2, as illustrated in Figure 9. In order to en- 
large the window 53 to completely fill the landscape-ori- 
ented display screen 2 of Figure 9, second conventional 
zoom processing must be used to expand the window *o 
54, as illustrated in Figure 10. The window 54 is thus 
enlarged with a different form factor of height and width 
to substantially fill the screen as completely as possible 
without covering the menu bar 12 or the icons 1 3. 

In accordance with the preferred embodiment of the «5 
present invention, a window may be automatically zoom 
processed when the display screen is flipped. Figure 1 0 
is illustrative of the result obtained when the display 
screen of Figure 8 is flipped from portrait to landscape 
orientation, and the window 52 is automatically zoom so 
processed. In accordance with the present invention, 
automatic zoom processing maintains the same relative 
spacing between the edges of windows and the corre- 
sponding edges of display screens so that the menu bar 
12 and icons 1 3 remain accessible. Conventional data 55 
processing may be used (e.g., 'Cleanup Desktop" pro- 
gram available from Apple Computer, Inc.) to move the 
icons 1 3 in response to a flip between orientations of the 



Bn^^mi 



e 



display screen, some windows, particularly windows 
known as "dialog boxes, ' are not capable of being re- 
sized by conventional window processing, and are not 
resized in accordance with the present invention follow- 
ing a flip between display screen orientations. 

Referring now to Figure 1 1 , there is shown a display 
of a control panel 66 which enables a' user to disable 
certain features provided in accordance with the present 
invention. The image of a control panel switch 61 on this 
display 66 indicates that the window positioning feature 
is enabled. Another image of a control panel switch 62 
on this display 66 indicates that the window resizing fea- 
ture is enabled. A third image of a control panel switch 
63 on this display 66 indicates that the finder cleanup 
feature, which relocates icons, is enabled. The image of 
a control 64 on this display 66 indicates adjustment of 
the display after the screen flip to account for any minor 
irregularities. Another image of a switch 65 is provided 
on this display 66 which indicates that all of the flip fea- 
tures are enabled. A user may alter any of the switch 
images 61 through 65 using conventional window-and- 
button technology by positioning a display cursor (not 
shown) over the desired switch position and clicking a 
button on the mouse of the computer system (not 
shown). 

Referring now to Figures 1 1 (a) and 1 1 (b), more de- 
tail is shown regarding the image of the window resizing 
control panel switch 62. The image of this control panel 
switch 62 indicates two functions. The first function, al- 
ready described, is to allow the window resizing feature 
to be disabled. The second function is to allow the auto- 
re zoom feature, in accordance with the present inven- 
tion, to be disabled. When a user points to, and selects, 
the icon 90 of Figure 11(a) with the mouse, using con- 
ventional window-and-button technology, the icon 90 
changes to the icon 91 of Figure 11(b) : indicating that 
the auto-rezoom feature has been disabled. 

It is not feasible to reposition the windows provided 
with some conventional computer programs. Figure 1 2 
illustrates a control panel window that indicates to a user 
ways in which to customize specific windows of specific 
computer programs. 

The preferred embodiment of the invention makes 
use of a number of prior art routines to move and resize 
windows. Figure 1 3(a) illustrates these routines. In order 
for the invention to move or resize a window, certain in- 
formation must be saved for each window which is cur- 
rently in use. The prior art routine NewWindow 104 im- 
plements the allocation and initialization of the required 
additional information. When a window is closed, the ad- 
ditional information is no longer needed. The prior art 
routine Close Window 107 is used to de-allocate the 
storage allocated by NewWindow. The prior art routine 
GetNextEvent 1 02 is used to coordinate the flip-related 
actions such as flip detection, window movement and 
window resizing, with the op rating system I the com- 
puter. 

In accordance with the invention, when a flip is de- 
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tected, a list of existinpPfdows is created. During soft- 
ware calls to the GetNextEvent routine 102, the prior art 
routines QetMouse 1 1 5 and Button 1 1 6 are used to sim- 
ulate manual manipulation of the mouse. The prior art 
routine ShbwHide 109 is used to move and resize ex- 
isting wind ws that are presently hidden from the user's 
view by a current application program. 

Prior art routines DragWindow 108, GrowWindow 
110 and Zoom Window 112 are used after a flip in ac- 
cordance with the present invention to correct the limits 
of a prior art constant called "screenBits.bounds" which 
sets corresponding parameters for window dragging, 
sizing and zooming. Some application programs employ 
prior art routines such as SizeWindow 111 instead of 
ZoomWindow 112. The prior art routines TrackBox 114 
and SizeWindow 11 1 are used with such application pro- 
grams. 

The prior art routines InltGraf 103 and InitWindows 
105 are used in accordance with the present invention 
to determine the amount of memory in an internal dis- 
play buffer required to be allocated for an application 
program, where an application supports such a buffer, 
to allow the application to properly present a display in 
either portrait or landscape orientation. Application pro- 
grams sometimes allocate such a buffer, based on the 
"screenBrts.bounds - constant, in order to speed up data 
presentation and refresh. 

The prior art routine MenuSelect 113 is used in ac- 
cordance with the present invention to reposition the 
icons in the conventional icon-based user interface typ- 
ically used with the invention. Similarly, the prior art rou- 
tine TextBox 117 is used to reposition menu bar appli- 
cation names when initiating such applications after a 
flip. 

The prior art routines InitZone 118, GetNextEvent 

1 02 and SelectWindow 1 06 are used in accordance with 
the present invention to allow processing of multiple ap- 
plication program windows which may be active in a 
"MultiFinder" environment typically found in computers 
used with the invention. In the MultiFinder environment, 
there may be several application programs running with- 
out their windows being directly accessible ("back- 
ground applications"). Typically the MultiFinder environ- 
ment only allows a single set of windows, those of the 
"foreground application", to be resized. In accordance 
with the present invention, a table of active application 
programs is maintained, and window resizing is accom- 
plished whenever an application is selected to become 
the foreground application. The prior art routine InitGraf 

103 is employed to prevent the removal of software 
"patches" made in accordance with the present inven- 
tion when a new application is initiated in the "MultiFind- 
er" environment. 

The prior art routine SlotManager 1 01 is used in ac- 
cordance with the present invention to allow the defini- 
tion of multiple video devices for versions of the operat- 
ing system of the c mputer which would otherwise only 
allow one video device, and therefor one orientation, 
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per hardware sloHfi accordance with the present inven- 
tion, each possible display orientation is consid red a 
separate device, and theref re it is essential that multi- 
ple devices be permitted. 

Miscellaneous support software routines 119 are 
provided in accordance with the preferred embodiment. 
These routines 119 are illustrated in detail in Figure 13 
(b) and their corresponding flow diagrams are given in 
Figures 32 through 41. 

Referring now to Figure 13(b). the routine Check/ 
Handle Flipped Dolphin (abbreviated "FlipOut") 3201 is 
the main routine for detecting when a flip is made and 
altering the windows accordingly. 

The routine Compute New Window Position (abbre- 
viated "PositionWindow*) 3301 calculates and modifies 
the bounding parameters of a window responsive to a 
display screen flip. 

The routine Check Resize List 3401 builds and 
processes the list of windows which need to be resized 
responsive to a display screen flip. 

The routine Resize Window 3501 generates phan- 
tom mouse clicks as required to resize a window respon- 
sive to a display screen flip. 

The routine Compute Resize Amount (abbreviated 
"CalcWindResize") 3601 calculates the amount by 
which a window must be resized responsive to a display 
screen flip in order for the window to remain accessible 
and logically placed on the flipped display. 

The routine Rebuild Desktop 3701 checks to see 
whether multiple displays are being used in the system 
and, if they are. changes the relationships between the 
display screens responsive to a display screen flip. 

The routine Finder Cleanup (or "CleanUpFinder") 
3801 generates phantom mouse clicks, responsive to a 
flip of the display screen, to initiate a prior art "Finder 
Cleanup* procedure. 

The routine Map Rectangle to Main Device (abbre- 
viated "MapBigRect") 3901 maps a given window size 
to best fit within the current dimensions of whichever dis- 
play contains the prior art main menu bar. 

The routine Process a New Window (abbreviated 
"ProcessNewWind") 4001 performs allocations re- 
quired to keep track of reorientation and resizing infor- 
mation, checks to make sure that window size is main- 
tained in accordance with a previous dimension of the 
display that it associated with, and if not, generates any 
phantom mouse clicks necessaryJo resize the window 
to the current dimensions of the associated display 

The routine Get Window's Graphic Device (abbre- 
viated "GetWindGD") 4101 determines which of the 
multiple displays is best associated with a window, con- 
sidering which of the top, left, bottom, and right edges 
of the window are contained in each display. 

Figures 14 through 31 illustrate in greater detail the 
manner in which the prbr art routines shown in Figure 
13(a) are "patched" in accordance with the present in- 
vention. Figur s 32 through 41 illustrate in greater detail 
the manner in which the ten routin s 6hown in Figure 
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1 3(b) operate in accords with the present invention. 

Referring now to Figure 14, the routine MySlotMan- 
ager 1 401 includes test 1402 to determin whether the 
prior art '32-Bit QuickDraw* System is running. If it is, 
then execution jumps immediately to the prior art s 
_SlotManager code 1408, because the different orien- 
tations of the present invention are implemented via 
32-Bit QuickDraw's Video families,* and hence, there is 
no need to modify data. Otherwise, test 1403 is per- 
formed to see if the calling algorithm is looking for a 10 
board data structure which might have to be modified to 
reflect the current orientation of the present invention. If 
the calling algorithm is not looking for such a structure, 
execution jumps immediately to the original 
_SlotManager code 1 408-Otherwise, test 1404 is per- is 
formed to determine if the calling algorithm is looking for 
the video circuit board data which specifies parameters 
for a video mode. If not, execution jumps immediately 
to the original .SiotManager code 1 408. Otherwise, test 
1405 is performed to determine whether the calling al- *o 
gorrthm is looking for video parameter board data of a 
board which supports changes in display orientation. If 
not, execution jumps immediately to the original 
_SlotManager code 1408. Otherwise, test 1406 is per- 
formed to determine if the board for which the video pa- zs 
rameters are being requested of is in landscape orien- 
tation. If not, execution jumps immediately to the prior 
art _SlotManager code 1408. Otherwise, the landscape 
bit of the identifying number of the board whose video 
parameters are being requested is set. Finally, execu- 30 
tion is transferred to the prior art _SlotManager code 
1408 with the modified identifying number. This patch 
allows for an operating system which is not running 
32-Bit QuickDraw to have access to the video parame- 
ters for both orientations of the present invention using 35 
only one board identifying number. The patch intercepts 
requests for video parameters from the present inven- 
tion, and modifies the board identifying number if the 
present invention is in landscape mode. Thus the prior 
art _SlotManager code returns the video parameters of *> 
the current orientation of the present invention, and thus 
simulates the effects of the prior art Video f amines' con- 
cepts of 32-Bit QuickDraw. 

Referring now to Figure 15, the routine MyGetNex- 
t Event 1 501 executes step 1 502 to check the list of win- 
dows that needs to be resized after a flip has occurred. 
It then executes the prior art _GetNextEvent code 1 503. 
Next, step 1504 is executed which checks for, and proc- 
esses, any flip which has occurred. Finally, it executes 
step 1 505 which provides any filtering required to assist so 
in the processing of phantom mouse events generated 
by the present invention. This patch provides a conven- 
ient location for the preferred embodiment of the present 
invention to detect and respond to a new monitor orien- 
tation resulting from the user flipping a display. It coor- ss 
dinates the resizing actions required tochange windows 
to a n w display orientation, as well as detecting chang- 
es in ori ntation and providing any filtering required dur- 
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ing the processing of phantom mouse events used to 
implement many of the effects of the present invention. 

Referring now to Figure 16, the routin MylnitGraf 
1 601 includes test 1602 to see if MultiFinder is executing 
on th machine, and if so, steps 1 603 and 1 604 are ex- 
ecuted to reinstall patches to the prior art routin s 
JnitWindows and _Closewindow. Otherwise, control 
transfers directly to the execution of step 1605 which 
calls the prior art JnrtGraf code. Finally, if needed, step 
1606 sets the prior art global variable "screenBits. 
bounds* to be a rectangle which encompasses the di- 
mensions of both orientations of the present invention. 
This patch does two things. First, if the prior art program 
•MultiFinder" is running, it reinstalls patches to prior art 
routines JnitWindows and .CloseWindow. which may 
have been removed. Second, if called by an application 
specified by the user as •incompatible," it sets the prior 
art global variable "screenBits. bounds' to be a rectangle 
which encompasses the dimensions of both orientations 
of the present invention. 

Referring nowto Figure 17, the routine MyNewWin- 
dow 1701 calls the prior art _NewWindow code 1702, 
and then executes step 1 703 which allocates and initial- 
izes a data structure used by the present invention to 
reposition and/or resize the window after a change in 
display orientation has been made. This patch provides 
a convenient place for the present invention to create 
any additional data structures required to process the 
new windows after a change in display orientation. 

Referring nowto Figure 18, the routine FliplnitWin- 
dows 1801 executes step 1802 to retrieve the current 
bottom right comer of the prior art global parameter 
"screenBits. bounds. ' Next, step 1 803 is executed to set 
the bottom right comer of the prior art global "screenBits. 
bounds' to match the current dimensions of the display 
which contains the menu bar. Next the prior art 
JnitWindows code 1804 is executed. Step 1805 is then 
executed to restore the bottom right comer of the prior 
art global screen Bits, bounds to its original value. Next, 
step 1806 is executed to make sure that the windows 
for which the present invention has allocated an extra 
data structure still exist in the system, and if not, to deal- 
locate the extra data structure. Finally, execution is re- 
turned to the caller 1807. This patch does two things 
First, it ensures that the bottom right corner of the prior 
art global "screenBits bounds" is correct during execu- 
tion of the prior art JnitWindows routine. Second, it 
makes sure that all of the windows for which the present 
invention has allocated an extra data structure still exist. 

Referring now to Figure 19, the routine FlipSe- 
lectWindow 1 901 executes step 1 902 to save the point- 
er to the window being selected into global storage. 
Next, execution passes directly to the prior art 
_SeiectWindow code 1903. This patch updates the 
pointer of the preferred embodiment to the topmost win- 
dow on the desktop, which is n eded for determining if 
a new application has become the curr nt application in 
a MultiFind r environment. 
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Referring now IBBfTgure 20, the routine Flip- 
CloseWindow 2001 executes step 2002 which deallo- 
cates the extra data structure allocated by th present 
inventbn when the window was creat d. Finally, execu- 
tion passes direct V t the prior art .Close Window code. 
This patch deallocates the extra data structure allocated 
by the present invention when the window was created, 
since once the window is closed, the extra data structure 
serves no purpose. 

Referring now to Figure 21 . the routine FlipDrag- 
Window 21 01 executes step 21 02 which creates a copy 
of the "boundsRect" parameter. Next, step 2103 is exe- 
cuted which remaps the "boundsRect" copy to match 
the dimensions of the display which contains the menu 
bar, if necessary. Next, the prior art _DragWindow code 
2 1 04 is executed, using the modified copy of the "bound- 
sRect* parameter. Next, step 2105 is executed which 
deallocates the "boundsRect" copy. Finally, execution is 
returned to the caller 2106. This patch insures that the 
"boundsRect" parameter matches the dimensions of the 
display which contains the menu bar. Applications nor- 
mally call the prior art JDragWindow routine using a 
"boundsRect" which matches the dimensions of the dis- 
play containing the menu bar when the application was 
launched. If this display is one that is capable of being 
flipped, and the user then flips the display, the "bound- 
sRect" parameter for subsequent _DragWindow calls 
will not match the current dimensions of the display. This 
patch then remaps a copy of the "boundsRect" param- 
eter to match the current dimension of the flipped dis- 
play. 

Referring now to Figure 22, the routine FlipShow- 
H ide 220 1 contains test 2202 which determines whether 
the prior art _ShowHide routine has been called from 
within the present invention. If so, execution transfers 
directly to the prior art _ShowHide code 2210. Other- 
wise, test 2203 is made to check for the existence of the 
extra data structure normally allocated to the window by 
the present invention. If no such data structure exists, 
execution transfers directly to the prior art _ShowHide 
code 2210. Otherwise, step 2204 is executed which 
copies the visible status of the window into the extra data 
structure. Next, test 2205 is made to determine if the 
calling procedure wants to hide the window. If the win- 
dow is being hidden, execution transfers directly to the 
prior art _ShowHide code 2210. Otherwise, a check is 
made to see if the window is visible. If it is, execution 
transfers directly to the prior art _ShowHide code 2210. 
Otherwise, step 2207 is executed to determine the cur- 
rent position/location of the window. Next, step 2208 is 
executed to adjust the position of the window (as need- 
ed) to the current desktop configuration, if allowed by 
the user. Next, if the window is of the type which can be 
resized, step 2209 is executed to add the window to the 
list of windows to be resized. Finally, execution transfers 
directly to the prior art _ShowHid code 2210. This 
patch facilitates the repositioning and resizing of win- 
dows which were not visible when the user flipped the 
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orientation of theTJisplay scr en in accordance with the 
present invention. 

Referring now to Figure 23, th routine FlipGrow- 
Window 2301 xecutes step 2302 which allocates a rec- 
5 tangle, assigns (4,MBarHeight+4) to the top-left comer 
and copies the sizeRect parameter's bottom-right to the 
temporary rectangle's bottom-right. Next, step 2303 is 
executed to map the temporary rectangle to the current 
size of the display which contains the menu bar. Next, 
io the prior art _GrowWindow routine 2304 is executed, us- 
ing the temporary rectangle in place of the prior art siz- 
eRect parameter. Finally, step 2305 deallocates the 
temporary rectangle. This patch insures that the siz- 
eRect parameter passed to the prior art _G row Window 
'5 routine matches the current size of the display which 
contains the menu bar. 

Referring now to Figure 24, the routine F lipSizeWin- 
dow 2401 executes step 2402 which creates a tempo- 
rary rectangle. Next, test 2403 is made to determine 
20 whether the prior art _SizeWindow routine is being 
called to implement a window zooming function. If it is 
not, execution transfers directly to the prior art 
_SizeWindow code 2408. Otherwise, step 2404 is exe- 
cuted to copy the position and size of the new window 
2S into the temporary rectangle. Next, step 2405 is execut- 
ed to map the temporary rectangle to the current size of 
the display with the menu bar. Next, test 2406 is execut- 
ed which determines if the window will have to be addi- 
tionally resized so that it will be contained on the display 
30 with the menu bar. If not, execution transfers directly to 
the prior art _SizeWindow code 2408. Otherwise, step 
2407 generates phantom mouse events, by mimicking 
the code generated when a user points and clicks with 
a mouse, based on the remapped temporary rectangle 
35 to further resize the window. Next, the prior art 
.SizeWindow code 2408 is called. Next, step 2409 is 
executed, which saves the new position and size of the 
window if the prior art _SizeWindow routine was in- 
voked. Finally, step 2410 is executed to deallocate the 
40 temporary rectangle. This patch makes sure that appli- 
cations which zoom windows using the prior art 
.SizeWindow routine (instead of the prior art 
_ZoomWindow routine) correctly zoom the window to 
the current size of the display containing the menu bar. 
45 Referring now to Figure 25, the routine Flip- 
ZoomWindow 2501 contains test 2502 which deter- 
mines if the standard state rectangle of the window is 
the same as its user state rectangle. If not, control pass- 
es directly to step 2504. Otherwise, step 2503 is called 
so to map the user state rectangle to current size of the 
display containing the menu bar. Next, step 2504 maps 
the standard state rectangle to the current size of the 
display with the menu bar. Next, the prior an 
.ZoomWindow code 2505 is executed. Next, test 2506 
55 is made to determine if the prior art .Zoom Window rou- 
tine was called t rezoom a window to match a new dis- 
play orientation due t the user flipping the display. If 
not, xecution is immediately returned to the caller 
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2508. If so. step 2507 rSHores the user state rectangle 
to its prezoom state. Next, execution is returned to the 
caller 2508. This patch performs two functions. First, it 
makes sure that the user state and standard state rec- 
tangles for the window being zoomed map pr p rry to s 
the current dimensions of the display with the menu bar. 
The second function performed by the patch allows the 
user to zoom back in to a small standard state after a 
rezooming operation. This is accomplished by storing 
the small standard state rectangle, and restoring this io 
value after the call to the prbr art _ZoomWindow routine 
(which may alter the standard state rectangle to be an 
undesirable value). 

Referring now to Figure 26, the routine FlipMen- 
uSelect 2601 includes test- 2602 which determines if the is 
Finder is being invoked to perform a cleanup operation. 
If not, control passes immediately to the prior art 
_MenuSelect code 2603 Otherwise, the prior art 
_MenuSelect code 2604 is called as a subroutine. Next, 
step 2605 replaces the result of the call with the menu 20 
item identifier of Special-Cleanup. Finally, control is re- 
turned to the caller 2606. This patch facilitates invoking 
a Finder cleanup operation by returning the menu item 
identifier of Special-Cleanup when called. 

Referring nowto Figure 27, the routine FlipTractBox 2S 
2701 calls the prior art _TrackBox code 2702. Next, it 
executes step 2703 which copies the result into global 
storage. Finally, it returns to the caller 2704. This patch 
saves the result of the call to the prior art _TrackBox 
routine so that it may later be examined by the 30 
_SizeWindow patch, to determine if _SizeWindow is be- 
ing called to zoom a window. 

Referring now to Figure 28, the routine FlipGet- 
Mouse 2801 calls the prior art _GetMouse code 2802. 
Next, it performs test 2803 which determines if a phan- 35 
torn mouse event is being generated. If not, control is 
immediately returned to the caller 2807. Otherwise, test 
2804 is performed to make sure that the phantom 
mouse up event is still in the event queue of the system. 
If so, step 2805 is executed which returns the phantom to 
mouse position instead of the actual position of the 
mouse on the display. If not, step 2806 is executed 
which cancels the phantom mouse event. In either case, 
execution next returns to the caller 2807. This patch per- 
mits the acceptance by application programs of phan- ** 
torn mouse events generated in accordance with the 
present invention. It returns the phantom position for the 
mouse instead of the real position whenever a phantom 
mouse event is generated. 

Referring now to Figure 29, the routine FlipButton so 
2901 executes the prior art ..Button code 2902. Next, it 
performs test 2903 which determines if a phantom 
mouse event is generated. If not, control is immediately 
returned to the caller 2907. Otherwise, test 2904 is per- 
formed which determines if the button counter of the ss 
present invention is greater than zero. If not, execution 
immediately returns t the caller 2907. Otherwise, step 
2905 is executed which decrements th button counter. 



Next, step 2906 is called which forces the return value 
of the prior art .Button r utine to be TRUE. Finally, ex- 
ecution returns to th caller 2907. This patch permits 
application programs to accept the phantom mouse 
events generated in accordance with the present inven- 
tion. It returns TRUE for a specified number of iterations 
instead of the real condition of the mouse button when- 
ever the preferred embodiment is generating a phantom 
mouse event. 

Referring now to Figure 30, the routine FlipButton 
3001 calls step 3002 which creates a temporary rectan- 
gle. Next, it executes test 3003 which determines if the 
current drawing port belongs to the prior art Window- 
Manager. If not, control passes to steps 3006. Other- 
wise, test 3004 is made to determine if the location of 
the text box is in the menu bar. If not, control passes to 
step 3006. Otherwise, code 3005 is executed which as- 
signs the temporary rectangle to the proper size for the 
current orientation of the display with the menu bar, and 
substitutes the temporary rectangle for the original box 
parameter. Next, the prior art JTextBox code 3006 is ex- 
ecuted. Next, step 3007 deallocates the temporary rec- 
tangle. Finally, execution is returned to the caller 3006. 
This patch fixes a Finder-based incompatibility with dis- 
plays capable of multiple orientations, such as those in 
accordance with the present invention. It insures that the 
Finder will place the names of launched applications in 
the center of the menu bar. 

Referring now to Figure 31 , the routine FliplnitZone 
3101 executes step 31 02 which removes ail entries from 
the process table of the preferred embodiment which 
have a ZonePtr that lies within the new heap zone being 
initialized. Next, control is passed to the prior art 
JnitZone code 3103. This patch assists the preferred 
embodiment in maintaining a process table when run- 
ning in a MultiFinder environment. There is no accepted 
method for determining when a process under the Mul- 
tiFinder environment quits. Therefore, the table of proc- 
esses of the preferred embodiment is updated when a 
new process is started, during which its zone is initial- 
ized. 

Referring now to Figure 32, the routine FlipOut 3201 
includes test 3202 which determines whether a monitor 
has been flipped. If not, control is returned to the caller 
3213. Otherwise, step 3203 is executed to cause the 
flipped display to fade its image to black. Next, step 3204 
is executed which checks windows to determine if they 
are in their standard (or 'zoomed-out') state. Next, step 
3205 is executed which builds an adjacency map of all 
of the displays currently operating in the system. Next, 
step 3206 is executed to resize the flipped display's prior 
art global GDevice record. Next, step 3207 is executed 
to reposition active displays as needed (to cope with the 
change in dimensions of the flipped device), and to up- 
date the prior art 'Scm' system resource. Next, step 
3208 is executed to modify all prior art Graf Ports which 
are based on the flipped device, updating them t the 
device's new rientation. Next, step 3209 is executed to 
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rebuild the prior art^Bai GrayRgn to match the new 
configuration of the displays. Next, step 321 0 is execut- 
ed to reposition windows as needed, so that they are 
still accessible under the new configuration of displays. 
Next, step 3211 is executed to rebuild the prior art s 
mouse/cursor data structures. Next, step 3212 is exe- 
cuted to repaint the displays, and to fade the image on 
the flipped display back in so that it is once again visible. 
Finally, control is returned to the caller 3213. This code 
determines if a display is flipped, and if so, provides all 10 
of the basic processing to update prior art operating sys- 
tem global structures to best cope with the change. 

Referring now to Figures 33(a), 33(b), 33(c) and 33 
(d), the routine Position Window 3301 includes test 3302 
which determines it the window is the same size as one is 
of the possible orientations of the display containing the 
menu bar. If so. control is passed directly to step 3326. 
If not, step 3X3 is executed which computes the mini- 
mum top-left value that the window's prior art portRect 
variable can achieve. Next, step 3304 is called which 20 
returns the bounding rectangle of the display with which 
the window is best logically associated. Next, test 3305 
is made to determine if the display associated with the 
window is the display containing the menu bar. If not, 
control is passed to step 3307. Otherwise, step 3306 is 2* 
executed which modifies the bounding rectangle of the 
associated display so that it reflects the minimum top 
and bottom offsets which that window must maintain 
within its associated display (determined by the user on 
an application-by-application basis; default values are 30 
0). Next, test 3307 is performed which determines if the 
associated display contained the bottom edge of the 
window before the user flipped the display. If not, control 
is passed to step 3310. Otherwise ; test 3308 is made 
which determines if the associated display still contains 35 
the bottom edge of the window. If so : control is passed 
to step 3310. Otherwise, step 3309 is executed which 
moves the window up so that the bottom edge remains 
on the associated display. Next, the test 3310 is per- 
formed which determines if the associated display con- *o 
tained the right edge of the window before the user 
flipped the current inventbn. If not, control is passed to 
step 3313. Otherwise, test 3311 is made which deter- 
mines if the associated display still contains the right 
edge of the window. If so, control is passed to step 331 3. *s 
Otherwise, step 3312 is executed which moves the win- 
dow left so that the right edge remains on the associated 
device. Next, test 3313 is performed which determines 
if the associated display contained the left edge of the 
window before the user flipped the current inventbn. If so 
not, control passes to step 3319. Otherwise, test 3314 
is made which determines if the left edge of the window 
is to the right of the right edge of the associated display. 
If so, control is passed to step 3316. Otherwise, test 

3315 is performed to check to determine if the associ- ss 
ated display contained the right edge of the window be- 
fore the user flipped the current invention. If not, step 

3316 is executed which moves the window left, so that 
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the left edge oTTFe window keeps a constant distance 
relative to the associated right edge of the display. Oth- 
erwise, test 3317 is performed which determines if the 
associated graphics device still contains the left edge of 
the wind w If so, control transfers to step 3319. Other- 
wise, step 3318 is executed which moves the window 
right so that the left edge remains on the associated dis- 
play. Next, test 3319 is performed which determines if 
the associated display contained the top edge of the 
window before the user flipped the display. If not, control 
passes to step 3326. Otherwise, test 3320 is made 
which determines if the top edge of the window is below 
the bottom edge of the associated display. If so, control 
is passed to step 3322. Otherwise, test 3321 is per- 
formed to check to determine if the associated display 
contained the bottom edge of the window before the us- 
er flipped the display. If not, step 3322 is executed which 
moves the window up, so that the top edge of the win- 
dow keeps a constant distance relative to the bottom 
edge of the associated display. Otherwise, test 3323 is 
performed which determines if the associated graphics 
device still contains the top edge of the window. If so, 
control transfers to step 3325. Otherwise, step 3325 is 
executed which moves the window down so that the top 
edge remains on the associated display. Next, step 
3325 is executed which adjusts the vertical position of 
the window so that it resides below the menu bar and 
ghost window, if necessary. This routine is responsible 
for repositioning a window after the user flips a display, 
so that it remains accessible and logically placed on the 
new orientation of the displays. 

Referring now to Figures 34(a) and 34(b), the rou- 
tine CheckResizeList 3401 includes test 3402 which de- 
termines if there are any pending events that the appli- 
cation needs to handle. If so, control is returned to the 
caller 3406. Otherwise, test 3403 is performed which de- 
termines if •mouse down* events are enabled. If not, 
control is returned to the caller 3406. Otherwise, step 
3404 is executed, which, if necessary, builds a new list 
of windows (in reverse order of their appearance on the 
desktop) and recalculates the application's menu sizes. 
Next, test 3405 is performed which checks to make sure 
that the reverse window list currently being processed 
is for the application currently executing. If not, control 
is returned to the caller 3406. Otherwise, test 3407 is 
performed which determines if there are any pending 
events that the application needs to handle. If so, control 
is returned to the caller 3414. Otherwise, test 3404 is 
performed which determines if the topmost window be- 
ing displayed is a dialog box. If so, control is returned to 
the caller 341 4. Otherwise, test 3409 is performed which 
determines if the reverse window list is empty. If so. step 
3412 is executed which directs the Finder to perform a 
cleanup operation, if necessary. Otherwise, step 3410 
is executed which removes the first window from the re- 
verse window list. Next, test 3411 is performed which 
determines if the window is still activ in the system. If 
not, control is passed to step 3407. Otherwise, step 
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3413 is executed, which resizes the window, if neces- 
sary. Finally, control is returned to the caller 3414. This 
routine builds and processes the list of windows which 
need to be resized after th user has flipped a display 
according to the present invention. 

Referring now to Figure 35, the routine ResizeWin- 
dow 3501 first executes step 3502 which computes the 
prior art variable portRect of the window in global coor- 
dinates. Next, it performs test 3503 which determines if 
the window was in its standard ("zoomed out") state be- 
fore the display was flipped by the user. If not, control is 
passed to step 3505. Otherwise, test 3504 is performed 
which determines if the window is still in its standard 
('zoomed out') state. If so, control is passed to step 
3505. Otherwise, step 3568 is executed which brings 
the window in front of all the other displayed windows. 
Next, step 3509 is executed which generates the phan- 
tom mouse clicks to coerce the window's application into 
rezooming to its standard state. Next, control is returned 
to the caller 351 0. Step 3505 calculates the amount that 
the window needs to be resized by in order for it to re- 
main fully accessible on the flipped display. Next, test 
3506 is performed which determines if the resize 
amount is non-zero. If not, control is returned to the call- 
er 3510. Otherwise, step 3507 is executed which gen- 
erates the phantom mouse clicks needed to perform the 
resizing. Finally, control is returned to the caller 3510. 
This routine generates the phantom mouse clicks need- 
ed, if any, to resize a window after the user has flipped 
a display of the present invention. 

Referring now to Figure 36, the routine CalcWin- 
dResize 3601 first executes step 3602 which returns the 
bounding rectangle of the display associated with the 
window being resized. Next, step 3603 is executed 
which zeros out local x and y delta variables which are 
used to determine the amount by which the window 
must be resized. Next, test 3604 is performed which de- 
termines if the bottom edge of the window was on the 
associated display before the user flipped the present 
invention. If not, control is passed to step 3609. Other- 
wise, test 3605 is performed which determines if the as- 
sociated display is the display with the menu bar. If not, 
control is passed to step 3607. Otherwise, the minimum 
bottom offset for the application of the window is sub- 
tracted from the rectangle of the associated display (off- 
set determined by the user on an application-by-appli- 
cation basis; default is zero) at step 3606. Next, test 
3607 is performed to determine if the bottom edge of the 
window still intersects the rectangle of the associated 
display. If so, control is passed to step 3609. Otherwise, 
step 3608 is executed which computes the delta y need- 
ed to keep the bottom edge of the window on the asso- 
ciated display. Next, test 3609 is performed which de- 
termines if the right edge of the window was on the as- 
sociated display before the user flipped the display. If 
not, control is passed to step 3612. Next, test 3610 is 
performed to check to determine if the right edge of the 
wind w still intersects the rectangle of the associated 



display. If so, control is pass d to step 3612. Otherwise, 
the procedure 3611 is called which computes the delta 
x needed t keep the right edge of the window on the 
associated display. Finally, step 3612 is called which 
5 computes global coordinates from the delta x and delta 
y local variables. This routine is responsible for comput- 
ing the amount which a window needs tobe resized after 
the user flips the display, so that the window remains 
accessible and logically placed on the new orientation 
10 of the displays. 

Referring now to Figures 37(a), 37(b), 37(c) and 37 
(d), the routine Rebuild Desktop 3701 first executes step 
3702 which returns the bounding rectangle of the first 
display in the computer system. Next, test 3703 is per- 
18 formed which determines if the display shared its top 
edge with another display before the user flipped the 
present invention. If not, control transfers to test 3706. 
Otherwise, test 3704 is made which determines if the 
displays were separated by the flip. If not, control trans- 
20 fers to step 3715. Otherwise, step 3705 is executed 
which moves the neighbor down, so the two displays 
once again share the same edge, and control transfers 
to step 3715. Test 3706 is performed which determines 
if the display shared its left edge with another display 
25 before the user flipped the orientation according to the 
present invention. If not, control transfers to step 3709. 
Otherwise, test 3707 is performed which determines if 
the displays were separated by the flip. If not, control 
transfers to step 3715. Otherwise, step 3708 is called 
so which moves the neighbor right, so the two displays 
once again share the same edge. Next, control transfers 
to step 3715. Test 3709 is performed which determines 
if the display shared its bottom edge with another display 
before the user flipped the present invention. If not, con- 
35 trol transfers to step 3712. Otherwise, test 3710ismade 
which determines if the displays were separated by the 
flip. If not, control transfers to step 3715. Otherwise, step 
3711 is called which moves the neighbor up, so the two 
displays once again share the same edge, and control 
transfers to step 371 5. If test 3709 reveals that there is 
no bottom neighbor, then test 3712 is performed which 
determines if the display shared its right edge with an- 
other display before the user flipped the present inven- 
tion. If not, control transfers to step 3715. Otherwise, 
45 test 371 3 is made which determines if the displays were 
separated by the flip. If not, control transfers to step 
3715. Otherwise, step 3714 is called which moves the 
neighbor left, so the two displays once again share the 
same edge. Next, test 3715 is performed which deter- 
80 mines if any displays were moved in order to reconnect 
edges. If so, control passes to step 3702. Otherwise, the 
procedure 3716 is called, which returns the next display 
in the system. Next, test 3717 is performed to make sure 
that a display was returned by step 3716. If so, control 
55 is transferred to step 3703. Otherwise, step 37 1 8 is ex- 
ecuted which sets the local variable CurrentGD to be 
the first display in the system. Next, step 3719 is exe- 
cuted to set the local variable CompareGD to be the first 
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display in the systenWf&xt, test 3720 is performed 
which determines if the Current CD display matches the 
CompareGD display. If so, control transfers to step 
3725. Otherwise, test 3721 is performed which deter- 
min s if the two displays overlap in coordinate space. If s 
not, control transfers to step 3725. Otherwise, test 3722 
is performed which determines if it is easier to move the 
CompareGD display to the right. If so, step 3723 is ex- 
ecuted to move the CompareGD display to the right so 
that the two displays only share coordinate space along io 
one edge, provided that the CompareGD display is not 
the left neighbor of the CurrentGD display, and that the 
CurrentGD display is not the right neighbor of the Com- 
pareGD display. Otherwise, step 3724 is executed to 
move the Compare GD display down so that the two dis- is 
plays only share coordinate space along one edge, pro- 
vided that the CompareGD display is not the top neigh- 
bor of the CurrentGD display, and that the CurrentGD 
display is not the bottom neighbor of the CompareGD 
display. In either case, step 3725 is called which assigns 20 
the local variable CompareGD with the next display in 
the system after its current value. Next, test 3726 is 
made which checks to make sure that the CompareGD 
is valid (that there actually is another display in the sys- 
tem). If so, control transfers to step 3720. If not, test 2s 
3727 is executed which determines if any displays were 
moved (changed coordinate systems). If so. control 
transfers to step 3718. If not, step 3728 is executed 
which assigns the local variable Current GD with the 
next display in the system after its current value. Next, 20 
test 3729 is made which checks to make sure the Cur- 
rent GD is valid (that there actually is another display in 
the system). If so, control transfers to step 371 9. Other- 
wise, step 3730 is executed which normalizes the coor- 
dinates of all of the systems in the display so that the 35 
upper-left comer of the display with the menu bar is a 
0,0. Finally, execution is returned to the caller 3731 . This 
procedure is responsible for rearranging the coordinate 
systems of the displays after the user flips a display of 
the present invention. 40 

Referring now to Figure 38, the routine CleanUp- 
Finder 3801 includes test 3802 which determines if this 
is the first pass through the routine since the user flipped 
a display of the present invention. If not, control passes 
to step 3803. If so, test 3805 is executed to check to 4S 
determine if the flipped display contained the menu bar. 
If not. control passes to step 3809. Otherwise, step 3806 
is executed which hides all of the visible windows of the 
Finder. Next, execution is returned to the caller 3810. 
Test 3803 determines if this is the second pass through so 
the routine since the user flipped a display of the present 
invention. If not, control passes to step 3804. If so : step 
3807 is executed which generates the phantom mouse 
clicks needed to coerce the Finder into commencing its 
cleanup operation. Next, execution is returned to the 55 
caller 381 0. Test 3804 determines if this is the third pass 
through the routine since the user flipped a display of 
the present invention. If not, control passes to step 3809. 
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Otherwise, stefJSOS is executed which shows all of tne 
windows of the Finder previously hidden by step 3806. 
Next, step 3809 is executed which causes the present 
invention to exit its Finder cleanup mode. Finally, exe- 
cution is returned to the caller 381 0. This procedure co- 
ordinates the activities needed to coerce the Finder into 
repositioning its desktop icons after the user has flipped 
a display. It is called as long as the present invention is 
in its Finder cleanup mode. 

Referring now to Figure 39, the routine MapBigRect 
3901 first calls step 3902 to get the first record in a list 
of possible sizes which the display with the menu bar 
may have. Next, step 3903 is executed which makes a 
temporary rectangle from the bounds in the display size 
record. Next, step 3904 expands the temporary rectan- 
gle by two pixels on each side. Next, test 3905 is exe- 
cuted which determines if the rectangle passed by the 
calling routine fits inside of the expanded temporary rec- 
tangle. If not, control passes to step 3910. Otherwise, 
step 3906 sets the top of the temporary rectangle to be 
the height of the menu bar. Next, step 3907 is executed 
to shrink the rectangle by 8 pixels left. 8 pixels right, 64 
top, and 64 bottom. Next, step 3908 is executed to move 
the right edge of the temporary rectangle in by 80 pixels. 
Next, test 3909 is performed which determines if the 
temporary rectangle will fit inside the passed-in rectan- 
gle. If so, step 3912 modifies the bottom-right comer of 
the passed-in rectangle, so that the bottom-right main- 
tains its distance relative to the current bottom-right cor- 
ner of the display with the menu bar. Next, control is re- 
turned to the caller 391 3. Step 391 0 gets the next record 
in the list of possible sizes which the display with the 
menu bar may have. Next, test 3911 is performed to 
check to make sure that the record just retrieved exists. 
If so, execution transfers to step 3903. Otherwise, con- 
trol is returned to the caller 3913. This procedure maps 
a given rectangle (usually representing the standard 
state of a window) to best fit inside the current dimen- 
sions of the display with the menu bar. 

Referring now to Figure 40, the routine Process- 
NewWind 4001 first executes step 4002 which creates 
an auxiliary data record tor the window, so that the 
present invention may keep track of certain additional 
data relating to the window. Next, test 4003 is per- 
formed, which determines if the window is growable. If 
not, control is returned to the caller 4009. If so, test 4004 
is performed, which determines if the window fits within 
the current bounds of the display with the menu bar If 
so. control is returned to the caller 4009. if not, test 4005 
is performed, which determines if the window can logi- 
cally be mapped to the current dimensions of the display 
with the menu bar. If not, control is returned to the caller 
4009. If so. test 4006 is performed, which determines if 
the window is visible. If so, step 4007 is executed which 
generates phantom mouse clicks to resize the window 
so that it fits within the current dimensions of the display 
with the menu bar. If not, step 4008 is executed, which 
adds the window to the list f windows to be resized, for 
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later action. After erth IWZe, control is next returned to 
the caller 4009. This routin performs two functions. 
First, it allocates the extra data structure used to keep 
track of key information needed in reorienting/resizing 
a window after the user flips a display. Second it checks 5 
the size of the window t make sure that it is sized ac- 
cording to a previous dimension of the display that it as- 
sociated with. If it is not the right size, mouse clicks are 
generated to resize the window to the current dimen- 
sions of the associated display. io 

Referring now to Figures 41(a) and 41(b), the rou- 
tine GetWindQD 4101 first executes step 4102 which 
returns a rectangle containing the coordinates of the vis- 
ible portion of the window translated to the display co- 
ordinate system. Next, step 41 03 is executed which gets '5 
the coordinates of the first display device in the system. 
Next, test 4104 is performed using the rectangles rep- 
resenting the window and display, which determines if 
the device contains the top edge of the window. If not, 
control is passed to step 4106. Otherwise, step 4105 is 20 
executed which adds the quantity eight to a weighted 
sum of the window for determining which display will be 
associated with the window. Next, test 4106 is per- 
formed, which determines if the device contains the left 
edge of the window. If not, control is passed to step 
4 1 08. Otherwise, step 41 07 is executed which adds the 
quantity four to the weighted sum. Next, test 4108 is per- 
formed, which determines if the device contains the bot- 
tom edge of the window. If not, control is passed to step 
41 1 0. Otherwise, step 41 09 is executed which adds the &> 
quantity two to the weighted sum. Next, test 4110 is per- 
formed, which determines if the device contains the right 
edge of the window. If not, control is passed to step 
4112. Otherwise, the step 4111 is called which adds the 
quantity one to the weighted sum. Next, test 41 1 2 is per- 35 
formed, which determines if the weighted sum for this 
device is the largest one found so far. If not, control is 
passed to step 4114. Otherwise, step 4113 saves the 
score and associated device in the auxiliary data struc- 
ture for the window. Next, test 4114 is performed which <o 
determines if there are any more display devices in the 
system. If not, control passes to step 4116. Otherwise, 
step 4115 gets the bounds of the next display in the sys- 
tem. Next, control passes to step 4104. Test 4116 de- 
termines if the highest score obtained was zero. If not, 45 
control passes tostep4118. Otherwise, step4117is ex- 
ecuted which associates the display containing the 
menu bar with the window. Next, step 4116 is executed 
which computes the window offsets from the associated 
display's top-left and bottom-right comers. Finally, con- so 
trol is returned to the caller 4119. This routine deter- 
mines which display is best associated with the window, 
which aids in maintaining the window's relative appear- 
ance when the user flips a display of the current inven- 
tion. Weighting is given to the display containing the top, 55 
left, bottom, and right edges of the window, in that order. 

Although the preferr d embodiment operates n 
defined windows in a two-scr en computer display sys- 
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tern, the inventiorTTs also useful where an image may 
be presented on one or more displays of any sort, the 
orientation of which is not completely fixed 

Therefore, a method is provided for moving and re- 
sizing computer display windows when a computer dis- 
play screen is flipped between portrait orientation and 
landscape orientation. 



Claims 

1 . A method of providing a display for a computer us- 
ing a display device (34, 41 ) providing at least one 
display window (10, 11) according to a set of rules, 
characterized by selectively positioning the display 
device (34 : 41) in one of a plurality of physical ori- 
entations (1 , 2). detecting (3202) a change in phys- 
ical orientation (1 , 2) of the display device (34, 41 ), 
determining a coordinate system (42, 44) describ- 
ing locations on said display device (41 ) in said 
changed orientation (2), generating (3207) a desk- 
top facility lor producing the display window accord- 
ing to said coordinate system, updating (3208, 
3210) position and size characteristics of the dis- 
play window (10, 11) according to the coordinate 
system, updating (321 1 ) limits for cursor and mouse 
movement according to the coordinate system, and 
repainting (3212) the display window on the display 
device (2). 

2. The method of claim 1 , characterized in that the set 
of rules includes a rule to maintain the relative dis- 
tance from a selected location on the window (10, 
1 1 ) to a selected location (24) on the display device. 

3. A method as in claim 1 or 2, further characterized 
in that the display comprises a computer video dis- 
play which is located on a plurality of display 
screens (34, 35) and the set of rules includes a rule 
to determine which of the plurality of display 
screens (34, 35) controls the window (38). 

4. A method as in claim 3, further characterized in that 
the moving and resizing of the window (38) are re- 
sponsive to the change in orientation of the display 
screen (35) which controls the window (38). 

5. A method as in claims 3 or 4, further characterized 
in that the display screen (35) which controls the 
window (38) is determined by weighting the impor- 
tance of various edges of the window (38), comput- 
ing a weighted sum for each display screen (35) on 
which a portion of the window (38) appears, and as- 
signing control of the window (38) to the display 
screen (35) with the greatest weighted sum. 

6. A method as in claim 5, further characterized in that 
the weighted sum is computed by adding 8 to the 
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weighted sum of^^lay screen (35) if that display 
screen (35) contains the top edge of the window 
(38), adding 4 to the weighted sum of a display 
screen (35) if that display screen (35) contains the 
left edge of the window (38), adding 2 to the weight- s 
ed sum of a display screen (35) If that display screen 
(35) contains the right edge of the window (38), and 
adding 1 to the weighted sum of a display screen 
(35) if that display screen (35) contains the bottom 
edge of the window (38). w 

7. A method as in claims 5 or 6, further characterized 
in that the location of a window (38) controlled by a 
display screen (35) relative to that display screen 
(35) remains unchanged in response to the change w 
in orientation of any other display screen (34, 35). 

8. A method as in one of the preceding claims, further 
characterized in that the set of rules includes a rule 
such that a first change in orientation of the display 20 
screen (1 ) followed by a second change in orienta- 
tion of the display screen back (1 ) to the initial ori- 
entation of the display screen results in the display 
window ( 1 1 ) of the display having the same position 
and size as it had before the first change in orien- 2s 
tation. 

9. A method as in one of the preceding claims, further 
characterized in that the set of rules includes a rule 
to resize the display window (11 ) of the display au- 30 
tomatically responsive to a change in orientation of 
the display screen (1 ) to more completely fill the re- 
oriented display screen (2) with the display window 
(11) of the display. 

3S 

10. A method as in one of the preceding claims, further 
characterized in that the display window (11 ) of the 
display is moved and resized by executing compu- 
ter code statements that mimic computer execution 
responsive to a user moving and resizing the dis- *o 
play window (11 ) using a pointing device. 

11. A method as in one of the preceding claims, further 
characterized in that the set of rules comprises a 
plurality of strategies for moving and resizing the 45 
portion of the display responsive to identification of 
the type of computer program producing the portion 
of the display. 
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Patentanspruche 



1. Verfahren zum Vorsehen einer Anzeige fur einen 
Computer, der eine Anzeigevorrichtung (34, 41) 
verwendet, die wenigstens ein Anzeigefenster (10, 55 
11 ) gemaG einer Gruppe von Regeln vorsieht, ga- 
le nnzei hnet durch selektives Positionieren der 
Anzeigevorrichtung (34, 41 ) in einer von mehreren 



physischerorTentierungen (1, 2), Erfassen (3202) 
einer Veranderung der physischen Orientierung (1 , 
2) der Anzeigev rrichtung (34, 41 ), Ermitteln eines 
Koordinatensystems (42, 44), welches Positionen 
auf der Anzeigevorrichtung (41) in der v randerten 
Orientierung (2) beschreibt, Erzeugen (3207) einer 
Desktop-Einrichtung zum Erzeugen aes Anzeige- 
fensters gemaG diesem Koordinatensystem, Aktua- 
lisieren (3208, 3210) von Positions- und GroGen- 
merkmalen des Anzeigefensters (10, 11) nach 
MaGgabe des Koordinatensystems, Aktualisier n 
(321 1 ) von Grenzen fur die Cursor- und Mausbewe- 
gung nach MaGgabe des Koordinatensystems und 
emeutes Darstellen (3212) des Anzeigefensters 
auf der Anzeigevorrichtung (2). 

2. Verfahren nach Anspruch 1, dadurch gekenn- 
zeichnet, daG die Regelgruppe eine Regel zum 
Beibehatten des relativen Abstandes von einer aus- 
gewahlten Position auf dem Fenster (10, 11 ) zu ei- 
ner ausgewahlten Position (24) auf der Anzeigevor- 
richtung auf waist. 

3. Verfahren nach Anspruch 1 oder 2, dadurch go- 
ken nzeichnet, daG die Anzeige eine Compute r- 
bildanzeige umfaGt, welche auf mehreren Anzeige- 
schirmen (34, 35) liegt, und daG die Regelgruppe 
eine Regel zum Ermitteln, welcher der mehreren 
Anzeigeschirme (34, 35) das Fenster (38) kontrol- 
liert, umfaGt. 

4. Verfahren nach Anspruch 3, dadurch gekenn- 
zeichnet, daG das Bewegen und Verandern der 
GroGe des Fensters (38) abhangig von der Ande- 
rung der Orientierung des Anzeigeschirms (35) ist. 
der das Fenster (38) kontrolliert. 

5. Verfahren nach Anspruch 3 oder 4, dadurch ge- 
kennzeichnet, daG der Anzeigeschirm (35), der 
das Fenster (38) kontrolliert, ermittelt wird, indem 
die Wichtigkeit verschiedener Rander des Fensters 
(38) gewichtet wird, eine gewichtete Summe fur je- 
den Anzeigeschirm (35) berechnet wird, auf dem 
ein Teil des Fensters (38) erscheint. und die Kon- 
trolle des Fensters (38) dem Anzeigeschirm (35) mit 
der groGten gewichteten Summe zugewiesen wird. 

6. Verfahren nach Anspruch 5, dadurch gakenn- 
zelchnet, daG die gewichtete Summe berechnet 
wird, indem 8 zu der gewichteten Summe eines An- 
zeigeschirms (35) addiert wird, wenn dieser Anzei- 
geschirm (35) den oberen Rand des Fensters (38) 
enthalt, 4 zu der gewichteten Summe des Anzeige- 
schirms (35) addiert wird, wenn dieser Anzeige- 
schirm (35) den linken Rand des Fensters (38) ent- 
halt, 2 zu der gewichteten Summe ines Anzeig - 
schirms (35) addiert wird, wenn dieser Anz ige- 
schirm (35) den rechten Rand des Fensters (38) 
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enthait, und 1 zu MPwichteten Summe ines An- 
zeigeschirms (35) addiert wird, wenn dieser Anzei- 
geschirm (35) den unteren Rand des F nsters (38) 
enthait. 

5 

7. Verlahren nach Anspruch 5 Oder 6, dadurch go- 
kennzeichnet, daB die Position eines Fensters 
(38), das von einem Anzeigeschirm (35) kontrolliert 
wird. bei einer Anderung der Orientierung eines der 
anderen Anzeigeschirme (34, 35) relativ zu jenem 10 
Anzeigeschirm (35) unverandert bteibt 

8. Verlahren nach einem der vorangehenden AnsprG- 
che, dadurch gekennzoichnet, daB die Regelgrup- 

pe eine Regel enthatt_ gemaB der eine erste Ande- is 
rung der Orientierung des Anzeigeschirms (1) ge- 
folgt von einer zweiten Anderung der Orientierung 
des Anzeigeschirms (1 ) zuruck zu der Anfangsori- 
entierung des Anzeigeschirms zur Folge hat, daB 
das Fenster ( 11 ) der Anzeige dieselbe Position und 20 
GroBe wie vor der ersten Anderung der Orientie- 
rung hat. 
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9. Verlahren nach einem der vorangehenden Anspru- 
che, dadurch gekennzoichnet, daB die Regelgrup- 2S 
pe eine Regel enthait, bei der das Fenster (11) der 
Anzeige abhangig von einer Anderung der Orien- 
tierung des Anzeigeschirms (1) automatisch eine 
neue GroBe enthait, urn den neu ausgertchteten 
Anzeigschirm (2) mit dem Fenster (1 1 ) der Anzeige 30 
vollstandiger auszufullen. 

10. Verfahren nach einem der vorangehenden Anspru- 
che, dadurch gekennzoichnet, daB das Fenster 

(1 1 ) der Anzeige bewegt und seine GroBe verandert 35 
wird, indem Computercodeanweisungen ausge- 
fuhrt werden, welche abhangig davon sind, daB ein 
Benutzer das Fenster (11 ) mittels eines Zeigers be- 
wegt und seine GroBe verandert. 

40 

1 1 . Verlahren nach einem der vorangehenden Anspru- 
che, dadurch gekennzoichnet, daB die Regelgrup- 
pe mehrere Strategien zum Bewegen und Veran- 
dern der GroBe des Fensters der Anzeige umfas- 
sen, abhangig von der Identifikation der An des <s 
Computerprogramms, welches das Fenster der An- 
zeige erzeugt. 



Revendicationo 



so 



1. Procddd pour fournir un affichage d'ordinateur en 
utilisant un dispositif d'affichage (34, 41 ) f ournissant 
au moins une fendtre d'aff ichage (10, 11) seton un 
ensemble de regies. caractdrisd par les dtapes con- ss 
sistant a positionner sdlectrvement le dispositif d'at- 
f ichage (34, 41) selon rune de plusieurs denta- 
tions physiques (1, 2), a ddtecter (3202) un chan- 



gement dTPlrTtation physique (1, 2) du dispositif 
d'aff ichage (34, 41 ). k determiner un systeme de 
coordonndes (42, 44) decrrvant des emplacements 
4 sur le dispositif d'affichage (41) selon Tori ntation 
modifide (2), a produire (3207) un utiiitaire de bu- 
reau pour fournir ia fendtre d'affichage selon ledit 
systeme de coordonndes, a metlre a jour (3206, 
3210) des caracteristiques de position et de dimen- 
sion de la fendtre d'affichage (10. 11) selon le sys- 
teme de coordonndes, k mettre k jour (3211) des 
limites de ddplacement de curse ur et de souris se- 
lon le systeme de coordonndes, et k redessiner 
(3212) la fendtre d'affichage sur le dispositif d'affi- 
chage (2). 

2. Precede' selon ia revendication 1 , caractdrisd en ce 
que rensemble de regies comprend une regie de 
maintien de la distance relative entre un emplace- 
ment choisi sur la fendtre (10, 11) et un emplace- 
ment chotsi (24) sur le dispositif d'affichage. 

3. Procddd selon la revendication 1 ou 2, caractdrisd 
en ce que I'affichage comprend un affichage video 
d'ordinateur qui est dispose sur piusieurs dcrans 
d'affichage (34, 35) et ('ensemble de rdgies compor- 
ts une rdgle de ddtermination de ceiui des dcrans 
d'affichage (34, 35) qui commande la fendtre (38). 

4. Procddd seton la revendication 3, caractdrisd en 
outre en ce que le ddplacement et le redimensbn- 
nement de la fendtre (38) son t eff ectuds en rdponse 
au changement d'orientation de I'dcran d'affichage 
(35) qui commande la fendtre (38). 

5. Procddd selon la revendication 3 ou 4, caractdrisd 
en outre en ce que I'dcran d'affichage (35) qui com- 
mande la fendtre (38) est ddtermind en ponddrant 
I'importance des divers bords de la fendtre (38), en 
calculant une somme ponddrde pour chaque dcran 
d'affichage (35) sur lequel une partie de la fendtre 
(38) apparalt, et en affectant la commande de la fe- 
ndtre (38) k I'dcran d'affichage (35) de plus grande 
somme ponddrde. 

6. Procddd selon la revendication 5, caractdrisd en 
outre en ce que la somme ponddrde est caiculde 
en ajoutant 8 A la somme ponddrde d'un dcran d'af- 
fichage (35) si cet dcran d'affichage (35) contient le 
bord supdrieur de la fendtre (38). en ajoutant 4 k la 
somme ponddrde cf un dcran d'affichage (35) si cet 
dcran d'affichage (35) contient le bord gauche de la 
fendtre (38) : en ajoutant 2 k ia somme ponddrde 
d'un dcran d'affichage (35) si cet dcran d'affichage 
(35) contient le bord droit de la fendtre (38) et en 
ajoutant 1 k la somme ponddrde d'un dcran d'affi- 
chage (35), si c t dcran d'affichag (35) contient le 
bord infdrieurde la fendtre (38). 
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en outre en ce que Pemplac ment de la f enetre (38) 
commanded par un ecran d'affichage (35) par rap- 
port a cet ecran d'affichage (35) reste inchange en 
r6ponse a un changement d'orientation d'un autre 5 
6cran d'affichage (34, 35). 

8. Procede seton Tune des revend cations pr6ceden- 
tes, caracterise en outre en ce que I'ensemble de 
regies contient une regie telle qu'un premier chan- 10 
gement d'orientation de I'ecran d'affichage (1 ) suivi 
d'un second changement d'orientation de I'ecran 
d'affichage (1 ) en retour vers I'orientatton initiate de 
l'6cran d'affichage entraine que la fendtre (11) de 
I'affichage a les mernes position et dimension que is 
celies qu'elle avait avant le premier changement 
d'orientation. 

9. Procede selon Tune des revendications preceden- 
tes, caracterise* en outre en ce que I'ensemble de 20 
regies contient une regie de redimensionnement de 

la fendtre (1 1 ) de I'affichage, de facon automatique, 
en r6ponse k un changement d'orientation de 
I'ecran d'affichage (1) pour remplir plus complete- 
ment I'ecran d'affichage r6orient6 (2) par la fenStre & 
(11) de I'affichage. 

10. Precede selon I'une des revendications preceden- 
tes, caracterise en outre en ce que la fendtre (11) 

de I'affichage est deplacee et redimensionnee en 30 
executant des lignes de code d'ordinateur qui simu- 
lent I'execution de I'ordinateur en rgponse a un de- 
placement et k un redimensionnement par I'utilisa- 
teur de la fenetre (11) en utilisant un dispositif de 
pointage. 35 

11. Proced6 selon I'une des revendications pr6c6den- 
tes, caracteris6 en outre en ce que ('ensemble de. 
regies cornprend une plurality de strategies pour 
deplacer et redimensionner la partie de I'affichage <o 
en r6ponse a ''identification du type de programme 
d'ordinateur produisant la partie de I'affichage. 
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